ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group02b.txt/000046_icon-group-sender_Tue Sep 24 12:57:43 2002.msg

Internet Message Format | 2003-01-02 | 4KB

Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8OJvRM28525
    for icon-group-addresses; Tue, 24 Sep 2002 12:57:27 -0700 (MST)
Message-Id: <[e-mail]>
X-Sent: 24 Sep 2002 18:26:32 GMT
X-Sender: [e-mail]
Date: Tue, 24 Sep 2002 13:26:30 -0500
To: [e-mail]
From: "Nevin :-] Liber" <[e-mail]>
Subject: Re: Moving from Procedural to Object-Oriented (Was Re: Icon Wish
 List)
Errors-To: [e-mail]
Status: RO

>Andrew's post rings close to home, as my division is considering a
>move from a procedural language to an object-oriented one.

Good luck. :-)

>Accepting that on the one hand a LARGE system may benefit from the
>benefits of the object-oriented approach, while not forgetting that
>fads occur in all walks of life, including programming,

I don't think it is a fad.  It is just another tool in the toolbox.

>  I would appreciate if anyone in this group has seen the benefits vs
>the costs of moving from procedural to OO.

It is a bit too general a question.  It matters which language(s) you
are moving between.  For instance, if you are moving to C++, you get
a number of paradigms to use:  inheritance, RAII (Resource
Acquisition Is Initialisation) classes (the constructor acquires a
resource, and the destructor releases that resource; this works
because C++ destructors are called at well-defined times), generic
programming (templates), etc.  Other languages give you other
paradigms.

   Maybe also the "be sure to avoid" things.

Don't use a feature just because it is there; use it because it is
appropriate.  Not everything needs to be an object (unless your
language requires it).  Not everything needs to be a deep inheritance
tree.  Not every type of object needs to be designed for reuse.
Etc., etc.

When designing objects, try and avoid asking the object questions of
the form "what kind are you really"; this doesn't tend to scale.

Don't write new stuff procedurally just because your organisation
tends to be more comfortable doing so.

>For my part, I see the advantage of hiding data and reusing code,
>but this can be done with structured code and well-crafted libraries.

While certainly true (heck, you can do that in assembler too), the
more the language manages implicitly for the programmer, the less
buggy your software will be.  Lots of bugs in languages like C are
due to incorrect memory management (dangling pointers, memory leaks,
etc.); languages with garbage collection such as Icon never have
those kinds of problems; good discipline in C++ (using things like
Smart Pointer idioms, which is an RAII type of class) makes this much
easier than in C (not as easy as with GC, but more general, since it
can be applied to any type of resource, not just memory).  Making it
harder for programmers to express mistakes is a Good Thing.

There are, of course, development, performance and size penalties for
this, which your organisation has to use good engineering judgement
on whether the benefit is worth the cost.  And there will be a large
up front cost, as there tends to be lots of implicit undocumented
knowledge in old code bases that (hopefully) ends up being
rediscovered (and maybe even documented) in the new code base.  But
that rediscovery takes time.

OO isn't a panacea.  It is another way of doing things.  It is
another approach for expressing a design.
--
  Nevin ":-)" Liber  <mailto:[e-mail]>  [phone]